IBIS Macromodel Task Group Meeting date: 17 September 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis Kumar Keshavan Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz * Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None ------------- Review of ARs: - AR: Randy Wolff to draft a response to the BIRD198 authors. - Done. - Arpad Muranyi asked if there should be a formal AR for Michael and Randy to invite DDR memory and controller vendors to comment on new protocols. We agreed to make that an AR. Randy said he had asked for feedback within Micron but had none yet. [AR] Randy Wolff and Michael Mirmak to invite DDR memory and controller vendors to comment on new protocols. ------------------------- Review of Meeting Minutes: Arpad Muranyi asked for any comments or corrections to the minutes of the September 10 meeting. Walter Katz. moved to approve the minutes. Randy Wolff seconded the motion. There were no objections. ------------- New Discussion: BIRD198.1: Walter Katz asked if we had a response from Japan. Arpad Muranyi and Randy Wolff said there had been none. DC_Offset BIRD: Walter Katz showed "DC_Offset and VrefDQ". This was his third presentation on the topic. Slide 2: Walter felt slide 2 gave a good representation of DDR5 SDRAM. VrefDQ is voltage set by a register, with 100 to 200 settable values. The values would be between VDDQ and VSSQ with approx 0.5mV step size. The source might be a tapped series of resistors. JEDEC has requirements for the memory but not the controller. VrefDQ can be thought of as the reference. The controller picks the reference in a training sequence, approximating VrefDQ to the DC offset. The hardware sees a DQ signal, the midpoint of which is the DC offset. A differential amplifier calculates the difference between VrefDQ and the waveform. The software subtracts DC offset from DQ, by subtracting VrefDQ. The Rx out will be relative to VrefDQ. The EDA tool can offset by DC offset or VrefDQ, but VrefDQ is Model_Specific. Fangyi Rao asked if VrefDQ would be an In parameter. Walter said he would implement it as a register number, and it would be an Out. Ambrish Varma asked where the value for an In parameter would come from. Fangyi said it could come from a training sequence. Walter said in hardware the controller sets VrefDQ, and AMI models should do likewise. The model is likely to know the non-linearity of VrefDQ better than what the standard would have. Randy Wolff felt that knowing Vref would be better than knowing the offset. Transmitters that are not symmetric might see a greater difference between DC offset and VrefDQ. Walter said even if symmetric, the Tx would sweep up and down to pick a value near the middle. It may not be a perfect middle point due to the discrete steps. A large gain could be a problem due to saturation. The EDA tools wants to know VrefDQ. A Reserved_Parameter would be good. Fangyi noted that the slide showed no gain. He asked what the amp output would look like relative to ground. Walter said JEDEC only describe it as one way to implement an Rx, not THE way. Other receivers could differ. Fangyi said the Rx output would not be referenced to VrefDQ, it would be referenced to ground, and the Rx output would not be physical. Walter did not agree. Radek said having DQ by itself was not meaningful, it had to be referenced to something. Fangyi said on an scope it would be reference to ground. Walter accepted that. Fangyi said Rx out could not be compared to DQ only because their centers were side by side. It was a convenience. Slide 3: Walter said the controller would pick a VrefDQ between the high and low error limits. AMI_Init could pick a value closer to DC offset. In AMI_GetWave, non-linearities could be accounted for. Walter Katz showed EMD BIRD draft 20. Slide 4: Walter said in case shown, the controller was in control, not the Rx. It could control VrefDQ, Gain, and DFE taps. JEDEC gave only minimum and maximum values for those. Slide 5: Walter said the Rx could tell the Tx those settings, plus eye metrics. Training could only test for BER 1e-3 or 1e-4 due to simulation time limitations. The Rx could communicate jitter as an impulse response. That could be sent to the Tx. It could be done one of two ways: 1) BIRD147, using a file. The impulse response is not small, could impact performance. 2) (Slide 6) A new function argument. Fangyi asked how crosstalk would come from the Tx. Walter said the EDA tool accounted for crosstalk. Fangyi said the noise would be amplified. Michael Mirmak said one of the two must account for crosstalk. Walter felt the standard for that should be defined by the vendors, not IBIS. The impulse response might be the full response. The more information we transfer, the more approach #2 would be needed. Fangyi asked if slide 5 applied to both statistical and time domain. Walter said it was both. He described ways that might happen. Fangyi said the Rx would have to wait some number of bits before reporting eye height. Walter felt it might be 10,000 UI, but that was what the hardware would do anyway. Fangyi said that might take about 10 AMI_GetWave calls. Walter said synchronizing would not be trivial. Arpad suggested that some control for the range of acceptable block sizes would be needed. Walter said AMI_GetWave should be able to work with the input regardless of block size. Arpad said he would not want to have a problem similar to that seen with samples per bit. We will continue this topic next week. Enabling Back-channel in Statistical Mode: No discussion. Jitter HF/LF components and jitter amplification: No discussion. - Arpad: Motion to adjourn. - : Second. - Arpad: Thank you all for joining. ------------- Next meeting: 24 September 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives